Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multistream specs #15603

Open
wants to merge 11 commits into
base: develop
Choose a base branch
from
Open

Multistream specs #15603

wants to merge 11 commits into from

Conversation

samsondav
Copy link
Collaborator

Requires

Supports

Copy link
Contributor

github-actions bot commented Dec 10, 2024

AER Report: CI Core ran successfully ✅

aer_workflow , commit

AER Report: Operator UI CI ran successfully ✅

aer_workflow , commit

@samsondav samsondav force-pushed the MERC-6673 branch 3 times, most recently from f373e71 to 358a742 Compare December 10, 2024 17:27
@samsondav samsondav force-pushed the MERC-6673 branch 2 times, most recently from 00ca59b to 13192ab Compare December 10, 2024 19:45
}
}

func (s *streamRegistry) Get(streamID StreamID) (strm Stream, exists bool) {
func (s *streamRegistry) Get(streamID StreamID) (p Pipeline, exists bool) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the relation between job ids, stream ids, and pipeline ids? Seems like job and stream are analogous, and then 1 pipeline can have many streams (which is a specific type of job). Is that correct?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is a bit confusing. A job has exactly one pipeline_spec and those have two different IDs (we almost exclusively use the jobID to reference it though). stream_id is a completely different thing. So a job has one pipeline which may contain many stream IDs.

// This is a hack to support the legacy "Quote" case.
// Future stream specs should use streamID tags instead.
switch len(finaltrrs) {
case 1:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do these case values come from? Why is case 2 skipped?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see it's the number of results in the task run..Won't flexible schema result in a variable number of results - how would you know if it's benchmark/bid/ask vs bid/ask/marketDepth for example? Or is a taskRunResult just one stream result, and one stream result always one datapoint?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only needed for when you specify streamID at the job level, which this PR takes us away from. So we need to continue supporting this for the old use-case but for new cases its not relevant since the task can be tagged with a streamID

@samsondav samsondav requested a review from JoshC2k December 17, 2024 15:15
@samsondav samsondav requested a review from a team as a code owner December 18, 2024 15:05
@samsondav samsondav force-pushed the MERC-6673 branch 2 times, most recently from 446fb9c to f582bce Compare December 18, 2024 15:20
@samsondav samsondav force-pushed the MERC-6673 branch 4 times, most recently from dcea97e to 8b66587 Compare December 18, 2024 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants